<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>7.13. Migrating from Previous Versions</title>
<link rel="stylesheet" href="dbstyle.css" type="text/css">
<meta name="generator" content="DocBook XSL Stylesheets V1.72.0">
<link rel="start" href="index.html" title="Programmer's Reference Guide">
<link rel="up" href="zend.controller.html" title="Chapter 7. Zend_Controller">
<link rel="prev" href="zend.controller.exceptions.html" title="7.12. MVC Exceptions">
<link rel="next" href="zend.currency.html" title="Chapter 8. Zend_Currency">
<link rel="chapter" href="introduction.html" title="Chapter 1. Introduction to Zend Framework">
<link rel="chapter" href="zend.acl.html" title="Chapter 2. Zend_Acl">
<link rel="chapter" href="zend.auth.html" title="Chapter 3. Zend_Auth">
<link rel="chapter" href="zend.cache.html" title="Chapter 4. Zend_Cache">
<link rel="chapter" href="zend.config.html" title="Chapter 5. Zend_Config">
<link rel="chapter" href="zend.console.getopt.html" title="Chapter 6. Zend_Console_Getopt">
<link rel="chapter" href="zend.controller.html" title="Chapter 7. Zend_Controller">
<link rel="chapter" href="zend.currency.html" title="Chapter 8. Zend_Currency">
<link rel="chapter" href="zend.date.html" title="Chapter 9. Zend_Date">
<link rel="chapter" href="zend.db.html" title="Chapter 10. Zend_Db">
<link rel="chapter" href="zend.debug.html" title="Chapter 11. Zend_Debug">
<link rel="chapter" href="zend.dojo.html" title="Chapter 12. Zend_Dojo">
<link rel="chapter" href="zend.dom.html" title="Chapter 13. Zend_Dom">
<link rel="chapter" href="zend.exception.html" title="Chapter 14. Zend_Exception">
<link rel="chapter" href="zend.feed.html" title="Chapter 15. Zend_Feed">
<link rel="chapter" href="zend.filter.html" title="Chapter 16. Zend_Filter">
<link rel="chapter" href="zend.form.html" title="Chapter 17. Zend_Form">
<link rel="chapter" href="zend.gdata.html" title="Chapter 18. Zend_Gdata">
<link rel="chapter" href="zend.http.html" title="Chapter 19. Zend_Http">
<link rel="chapter" href="zend.infocard.html" title="Chapter 20. Zend_InfoCard">
<link rel="chapter" href="zend.json.html" title="Chapter 21. Zend_Json">
<link rel="chapter" href="zend.layout.html" title="Chapter 22. Zend_Layout">
<link rel="chapter" href="zend.ldap.html" title="Chapter 23. Zend_Ldap">
<link rel="chapter" href="zend.loader.html" title="Chapter 24. Zend_Loader">
<link rel="chapter" href="zend.locale.html" title="Chapter 25. Zend_Locale">
<link rel="chapter" href="zend.log.html" title="Chapter 26. Zend_Log">
<link rel="chapter" href="zend.mail.html" title="Chapter 27. Zend_Mail">
<link rel="chapter" href="zend.measure.html" title="Chapter 28. Zend_Measure">
<link rel="chapter" href="zend.memory.html" title="Chapter 29. Zend_Memory">
<link rel="chapter" href="zend.mime.html" title="Chapter 30. Zend_Mime">
<link rel="chapter" href="zend.openid.html" title="Chapter 31. Zend_OpenId">
<link rel="chapter" href="zend.paginator.html" title="Chapter 32. Zend_Paginator">
<link rel="chapter" href="zend.pdf.html" title="Chapter 33. Zend_Pdf">
<link rel="chapter" href="zend.registry.html" title="Chapter 34. Zend_Registry">
<link rel="chapter" href="zend.rest.html" title="Chapter 35. Zend_Rest">
<link rel="chapter" href="zend.search.lucene.html" title="Chapter 36. Zend_Search_Lucene">
<link rel="chapter" href="zend.server.html" title="Chapter 37. Zend_Server">
<link rel="chapter" href="zend.service.html" title="Chapter 38. Zend_Service">
<link rel="chapter" href="zend.session.html" title="Chapter 39. Zend_Session">
<link rel="chapter" href="zend.soap.html" title="Chapter 40. Zend_Soap">
<link rel="chapter" href="zend.test.html" title="Chapter 41. Zend_Test">
<link rel="chapter" href="zend.text.html" title="Chapter 42. Zend_Text">
<link rel="chapter" href="zend.timesync.html" title="Chapter 43. Zend_TimeSync">
<link rel="chapter" href="zend.translate.html" title="Chapter 44. Zend_Translate">
<link rel="chapter" href="zend.uri.html" title="Chapter 45. Zend_Uri">
<link rel="chapter" href="zend.validate.html" title="Chapter 46. Zend_Validate">
<link rel="chapter" href="zend.version.html" title="Chapter 47. Zend_Version">
<link rel="chapter" href="zend.view.html" title="Chapter 48. Zend_View">
<link rel="chapter" href="zend.xmlrpc.html" title="Chapter 49. Zend_XmlRpc">
<link rel="appendix" href="requirements.html" title="Appendix A. Zend Framework Requirements">
<link rel="appendix" href="coding-standard.html" title="Appendix B. Zend Framework Coding Standard for PHP">
<link rel="appendix" href="copyrights.html" title="Appendix C. Copyright Information">
<link rel="index" href="the.index.html" title="Index">
<link rel="subsection" href="zend.controller.migration.html#zend.controller.migration.fromoneohtoonefive" title="7.13.1. Migrating from 1.0.x to 1.5.0 or newer">
<link rel="subsection" href="zend.controller.migration.html#zend.controller.migration.fromzeroninethree" title="7.13.2. Migrating from 0.9.3 to 1.0.0RC1 or newer">
<link rel="subsection" href="zend.controller.migration.html#zend.controller.migration.fromzeroninetwo" title="7.13.3. Migrating from 0.9.2 to 0.9.3 or newer">
<link rel="subsection" href="zend.controller.migration.html#zend.controller.migration.fromzerosix" title="7.13.4. Migrating from 0.6.0 to 0.8.0 or newer">
<link rel="subsection" href="zend.controller.migration.html#zend.controller.migration.fromzerotwo" title="7.13.5. Migrating from 0.2.0 or before to 0.6.0">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader"><table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">7.13. Migrating from Previous Versions</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="zend.controller.exceptions.html">Prev</a> </td>
<th width="60%" align="center">Chapter 7. Zend_Controller</th>
<td width="20%" align="right"> <a accesskey="n" href="zend.currency.html">Next</a>
</td>
</tr>
</table></div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="zend.controller.migration"></a>7.13. Migrating from Previous Versions</h2></div></div></div>
<p>
        The API of the MVC components has changed over time. If you started
        using Zend Framework in an early version, follow the guidelines below to
        migrate your scripts to use the new architecture.
    </p>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="zend.controller.migration.fromoneohtoonefive"></a>7.13.1. Migrating from 1.0.x to 1.5.0 or newer</h3></div></div></div>
<p>
            Though most basic functionality remains the same, and all documented
            functionality remains the same, there is one particular
            <span class="emphasis"><em>undocumented</em></span> "feature" that has changed.
        </p>
<p>
            When writing URLs, the documented way to write camelCased action
            names is to use a word separator; these are '.' or '-' by default,
            but may be configured in the dispatcher. The dispatcher internally
            lowercases the action name, and uses these word separators to
            re-assemble the action method using camelCasing. However, because PHP
            functions are not case sensitive, you <span class="emphasis"><em>could</em></span>
            still write URLs using camelCasing, and the dispatcher would resolve
            these to the same location. For example, 'camel-cased' would become
            'camelCasedAction' by the dispatcher, whereas 'camelCased' would
            become 'camelcasedAction'; however, due to the case insensitivity of
            PHP, both will execute the same method.
        </p>
<p>
            This causes issues with the ViewRenderer when resolving view
            scripts. The canonical, documented way is that all word separators
            are converted to dashes, and the words lowercased. This creates
            a semantic tie between the actions and view scripts, and the
            normalization ensures that the scripts can be found. However, if the
            action 'camelCased' is called and actually resolves, the word
            separator is no longer present, and the ViewRenderer attempts to
            resolve to a different location -- 'camelcased.phtml' instead of
            'camel-cased.phtml'.
        </p>
<p>
            Some developers relied on this "feature", which was never intended.
            Several changes in the 1.5.0 tree, however, made it so that the
            ViewRenderer no longer resolves these paths; the semantic tie is now
            enforced. First among these, the dispatcher now enforces case
            sensitivity in action names. What this means is that referring to
            your actions on the url using camelCasing will no longer resolve to
            the same method as using word separators (i.e., 'camel-casing').
            This leads to the ViewRenderer now only honoring the word-separated
            actions when resolving view scripts.
        </p>
<p>
            If you find that you were relying on this "feature", you have several
            options:
        </p>
<div class="itemizedlist"><ul type="disc">
<li><p>
                    Best option: rename your view scripts. Pros: forward
                    compatibility. Cons: if you have many view scripts that
                    relied on the former, unintended behavior, you will have a
                    lot of renaming to do.
            </p></li>
<li>
<p>
                    Second best option: The ViewRenderer now delegates view
                    script resolution to <code class="code">Zend_Filter_Inflector</code>; you
                    can modify the rules of the inflector to no longer separate
                    the words of an action with a dash:
                </p>
<pre class="programlisting">&lt;?php
$viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
$inflector = $viewRenderer-&gt;getInflector();
$inflector-&gt;setFilterRule(':action', array(
    new Zend_Filter_PregReplace(
        '#[^a-z0-9' . preg_quote(DIRECTORY_SEPARATOR, '#') . ']+#i',
        ''
    ),
    'StringToLower'
));
?&gt;</pre>
<p>
                    The above code will modify the inflector to no longer
                    separate the words with dash; you may also want to remove
                    the 'StringToLower' filter if you <span class="emphasis"><em>do</em></span>
                    want the actual view script names camelCased as well.
                </p>
<p>
                    If renaming your view scripts would be too tedious or time
                    consuming, this is your best option until you can find the
                    time to do so.
                </p>
</li>
<li>
<p>
                    Least desirable option: You can force the dispatcher to
                    dispatch camelCased action names with a new front controller
                    flag, 'useCaseSensitiveActions':
                </p>
<pre class="programlisting">&lt;?php
$front-&gt;setParam('useCaseSensitiveActions', true);
?&gt;</pre>
<p>
                    This will allow you to use camelCasing on the url and still
                    have it resolve to the same action as when you use word
                    separators. However, this will mean that the original issues
                    will cascade on through; you will likely need to use the
                    second option above in addition to this for things to work
                    at all reliably.
                </p>
<p>
                    Note, also, that usage of this flag will raise a notice that
                    this usage is deprecated.
                </p>
</li>
</ul></div>
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="zend.controller.migration.fromzeroninethree"></a>7.13.2. Migrating from 0.9.3 to 1.0.0RC1 or newer</h3></div></div></div>
<p>
            The principal changes introduced in 1.0.0RC1 are the introduction of
            and default enabling of the
            <a href="zend.controller.plugins.html#zend.controller.plugins.standard.errorhandler" title="7.10.5.2. Zend_Controller_Plugin_ErrorHandler">ErrorHandler</a>
            plugin and the <a href="zend.controller.actionhelpers.html#zend.controller.actionhelpers.viewrenderer" title="7.8.4.7. ViewRenderer">ViewRenderer</a>
            action helper. Please read the documentation to each thoroughly to
            see how they work and what effect they may have on your
            applications.
        </p>
<p>
            The <code class="code">ErrorHandler</code> plugin runs during
            <code class="code">postDispatch()</code> checking for exceptions, and forwarding
            to a specified error handler controller. You should include such a
            controller in your application. You may disable it by setting the
            front controller parameter <code class="code">noErrorHandler</code>:
        </p>
<pre class="programlisting">&lt;?php
$front-&gt;setParam('noErrorHandler', true);
        </pre>
<p>
            The <code class="code">ViewRenderer</code> action helper automates view injection
            into action controllers as well as autorendering of view scripts
            based on the current action. The primary issue you may encounter is
            if you have actions that do not render view scripts and neither
            forward or redirect, as the <code class="code">ViewRenderer</code> will attempt
            to render a view script based on the action name.
        </p>
<p>
            There are several strategies you can take to update your code. In
            the short term, you can globally disable the
            <code class="code">ViewRenderer</code> in your front controller bootstrap prior
            to dispatching:
        </p>
<pre class="programlisting">&lt;?php
// Assuming $front is an instance of Zend_Controller_Front
$front-&gt;setParam('noViewRenderer', true);
        </pre>
<p>
            However, this is not a good long term strategy, as it means most
            likely you'll be writing more code.
        </p>
<p>
            When you're ready to start using the <code class="code">ViewRenderer</code>
            functionality, there are several things to look for in your
            controller code. First, look at your action methods (the methods
            ending in 'Action'), and determine what each is doing. If none of
            the following is happening, you'll need to make changes:
        </p>
<div class="itemizedlist"><ul type="disc">
<li><p>Calls to <code class="code">$this-&gt;render()</code></p></li>
<li><p>Calls to <code class="code">$this-&gt;_forward()</code></p></li>
<li><p>Calls to <code class="code">$this-&gt;_redirect()</code></p></li>
<li><p>Calls to the <code class="code">Redirector</code> action helper</p></li>
</ul></div>
<p>
            The easiest change is to disable auto-rendering for that method:
        </p>
<pre class="programlisting">
$this-&gt;_helper-&gt;viewRenderer-&gt;setNoRender();
        </pre>
<p>
            If you find that none of your action methods are rendering,
            forwarding, or redirecting, you will likely want to put the above
            line in your <code class="code">preDispatch()</code> or <code class="code">init()</code>
            methods:
        </p>
<pre class="programlisting">
public function preDispatch()
{
    // disable view script autorendering
    $this-&gt;_helper-&gt;viewRenderer-&gt;setNoRender()
    // .. do other things...
}
        </pre>
<p>
            If you are calling <code class="code">render()</code>, and you're using <a href="zend.controller.modular.html" title="7.11. Using a Conventional Modular Directory Structure">the Conventional Modular
                directory structure</a>, you'll want to change your code to
            make use of autorendering:
        </p>
<div class="itemizedlist"><ul type="disc">
<li><p>
                    If you're rendering multiple view scripts in a single
                    action, you don't need to change a thing.
                </p></li>
<li><p>
                    If you're simply calling <code class="code">render()</code> with no
                    arguments, you can remove such lines.
                </p></li>
<li><p>
                    If you're calling <code class="code">render()</code> with arguments, and
                    not doing any processing afterwards or rendering multiple
                    view scripts, you can change these calls to read
                    <code class="code">$this-&gt;_helper-&gt;viewRenderer()</code>.
                </p></li>
</ul></div>
<p>
            If you're not using the conventional modular directory structure,
            there are a variety of methods for setting the view base path and
            script path specifications so that you can make use of the
            <code class="code">ViewRenderer</code>. Please read the <a href="zend.controller.actionhelpers.html#zend.controller.actionhelpers.viewrenderer" title="7.8.4.7. ViewRenderer">ViewRenderer
                documentation</a> for information on these methods.
        </p>
<p>
            If you're using a view object from the registry, or customizing your
            view object, or using a different view implementation, you'll want
            to inject the <code class="code">ViewRenderer</code> with this object. This can
            be done easily at any time.
        </p>
<div class="itemizedlist"><ul type="disc">
<li>
<p>
                    Prior to dispatching a front controller instance:
                </p>
<pre class="programlisting">&lt;?php
// Assuming $view has already been defined
$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer($view);
Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
                </pre>
</li>
<li>
<p>
                    Any time during the bootstrap process:
                </p>
<pre class="programlisting">&lt;?php
$viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
$viewRenderer-&gt;setView($view);
                </pre>
</li>
</ul></div>
<p>
            There are many ways to modify the <code class="code">ViewRenderer</code>,
            including setting a different view script to render, specifying
            replacements for all replaceable elements of a view script path
            (including the suffix), choosing a response named segment to
            utilize, and more. If you aren't using the conventional modular
            directory structure, you can even associate different path
            specifications with the <code class="code">ViewRenderer</code>.
        </p>
<p>
            We encourage you to adapt your code to use the
            <code class="code">ErrorHandler</code> and <code class="code">ViewRenderer</code> as they are
            now core functionality.
        </p>
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="zend.controller.migration.fromzeroninetwo"></a>7.13.3. Migrating from 0.9.2 to 0.9.3 or newer</h3></div></div></div>
<p>
            0.9.3 introduces <a href="zend.controller.actionhelpers.html" title="7.8. Action Helpers">action helpers</a>.
            As part of this change, the following methods have been removed as
            they are now encapsulated in the <a href="zend.controller.actionhelpers.html#zend.controller.actionhelpers.redirector" title="7.8.4.6. Redirector">redirector
                action helper</a>:
        </p>
<div class="itemizedlist"><ul type="disc">
<li><p>
                    <code class="code">setRedirectCode()</code>; use
                    <code class="code">Zend_Controller_Action_Helper_Redirector::setCode()</code>.
                </p></li>
<li><p>
                    <code class="code">setRedirectPrependBase()</code>; use
                    <code class="code">Zend_Controller_Action_Helper_Redirector::setPrependBase()</code>.
                </p></li>
<li><p>
                    <code class="code">setRedirectExit()</code>; use
                    <code class="code">Zend_Controller_Action_Helper_Redirector::setExit()</code>.
                </p></li>
</ul></div>
<p>
            Read the <a href="zend.controller.actionhelpers.html" title="7.8. Action Helpers">action
                helpers documentation</a> for more information on how to
            retrieve and manipulate helper objects, and the <a href="zend.controller.actionhelpers.html#zend.controller.actionhelpers.redirector" title="7.8.4.6. Redirector">redirector
                helper documentation</a> for more information on setting
            redirect options (as well as alternate methods for redirecting).
        </p>
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="zend.controller.migration.fromzerosix"></a>7.13.4. Migrating from 0.6.0 to 0.8.0 or newer</h3></div></div></div>
<p>
            Per previous changes, the most basic usage of the MVC components
            remains the same:
        </p>
<pre class="programlisting">
require_once 'Zend/Controller/Front.php';
Zend_Controller_Front::run('/path/to/controllers');
        </pre>
<p>
            However, the directory structure underwent an overhaul, several
            components were removed, and several others either renamed or added.
            Changes include:
        </p>
<div class="itemizedlist"><ul type="disc">
<li><p>
                    <code class="code">Zend_Controller_Router</code> was removed in favor of
                    the rewrite router.
                </p></li>
<li><p>
                    <code class="code">Zend_Controller_RewriteRouter</code> was renamed to
                    <code class="code">Zend_Controller_Router_Rewrite</code>, and promoted to
                    the standard router shipped with the framework;
                    <code class="code">Zend_Controller_Front</code> will use it by default if
                    no other router is supplied.
                </p></li>
<li><p>
                    A new route class for use with the rewrite router was
                    introduced,
                    <code class="code">Zend_Controller_Router_Route_Module</code>; it covers
                    the default route used by the MVC, and has support for <a href="zend.controller.modular.html" title="7.11. Using a Conventional Modular Directory Structure">controller
                        modules</a>.
                </p></li>
<li><p>
                    <code class="code">Zend_Controller_Router_StaticRoute</code> was renamed
                    to <code class="code">Zend_Controller_Router_Route_Static</code>.
                </p></li>
<li><p>
                    <code class="code">Zend_Controller_Dispatcher</code> was renamed
                    <code class="code">Zend_Controller_Dispatcher_Standard</code>.
                </p></li>
<li>
<p>
                    <code class="code">Zend_Controller_Action::_forward()</code>'s arguments
                    have changed. The signature is now:
                </p>
<pre class="programlisting">
final protected function _forward($action, $controller = null, $module = null, array $params = null);
                </pre>
<p>
                    <code class="code">$action</code> is always required; if no controller is
                    specified, an action in the current controller is assumed.
                    <code class="code">$module</code> is always ignored unless
                    <code class="code">$controller</code> is specified. Finally, any
                    <code class="code">$params</code> provided will be appended to the
                    request object. If you do not require the controller or
                    module, but still need to pass parameters, simply specify
                    null for those values.
                </p>
</li>
</ul></div>
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="zend.controller.migration.fromzerotwo"></a>7.13.5. Migrating from 0.2.0 or before to 0.6.0</h3></div></div></div>
<p>
            The most basic usage of the MVC components has not changed; you can
            still do each of the following:
        </p>
<pre class="programlisting">
require_once 'Zend/Controller/Front.php';
Zend_Controller_Front::run('/path/to/controllers');
        </pre>
<pre class="programlisting">
/* -- create a router -- */
$router = new Zend_Controller_RewriteRouter();
$router-&gt;addRoute('user', 'user/:username', array('controller' =&gt; 'user',
'action' =&gt; 'info'));

/* -- set it in a controller -- */
$ctrl = Zend_Controller_Front::getInstance();
$ctrl-&gt;setRouter($router);

/* -- set controller directory and dispatch -- */
$ctrl-&gt;setControllerDirectory('/path/to/controllers');
$ctrl-&gt;dispatch();
        </pre>
<p>
            We encourage use of the Response object to aggregate content and
            headers. This will allow for more flexible output format switching
            (for instance, JSON or XML instead of XHTML) in your applications.
            By default, <code class="code">dispatch()</code> will render the response, sending both
            headers and rendering any content. You may also have the front
            controller return the response using <code class="code">returnResponse()</code>,
            and then render the response using your own logic. A future version
            of the front controller may enforce use of the response object via
            output buffering.
        </p>
<p>
            There are many additional features that extend the existing API,
            and these are noted in the documentation.
        </p>
<p>
            The main changes you will need to be aware of will be found when
            subclassing the various components. Key amongst these are:
        </p>
<div class="itemizedlist"><ul type="disc">
<li>
<p>
                    <code class="code">Zend_Controller_Front::dispatch()</code> by default
                    traps exceptions in the response object, and does not render
                    them, in order to prevent sensitive system information from
                    being rendered. You can override this in several ways:
                </p>
<div class="itemizedlist"><ul type="circle">
<li>
<p>
                            Set <code class="code">throwExceptions()</code> in the front
                            controller:
                        </p>
<pre class="programlisting">
$front-&gt;throwExceptions(true);
                        </pre>
</li>
<li>
<p>
                            Set <code class="code">renderExceptions()</code> in the response
                            object:
                        </p>
<pre class="programlisting">
$response-&gt;renderExceptions(true);
$front-&gt;setResponse($response);
$front-&gt;dispatch();

// or:
$front-&gt;returnResponse(true);
$response = $front-&gt;dispatch();
$response-&gt;renderExceptions(true);
echo $response;
                        </pre>
</li>
</ul></div>
</li>
<li><p>
                <code class="code">Zend_Controller_Dispatcher_Interface::dispatch()</code>
                now accepts and returns a <a href="zend.controller.request.html" title="7.4. The Request Object">Section 7.4, “The Request Object”</a>
                object instead of a dispatcher token.
            </p></li>
<li><p>
                <code class="code">Zend_Controller_Router_Interface::route()</code>
                now accepts and returns a <a href="zend.controller.request.html" title="7.4. The Request Object">Section 7.4, “The Request Object”</a>
                object instead of a dispatcher token.
            </p></li>
<li>
<p><code class="code">Zend_Controller_Action</code> changes include:</p>
<div class="itemizedlist"><ul type="circle">
<li><p>
                        The constructor now accepts exactly three arguments,
                        <code class="code">Zend_Controller_Request_Abstract $request</code>,
                        <code class="code">Zend_Controller_Response_Abstract $response</code>,
                        and <code class="code">array $params (optional)</code>.
                        <code class="code">Zend_Controller_Action::__construct()</code> uses
                        these to set the request, response, and invokeArgs
                        properties of the object, and if overriding the
                        constructor, you should do so as well. Better yet, use
                        the <code class="code">init()</code> method to do any instance
                        configuration, as this method is called as the final
                        action of the constructor.
                    </p></li>
<li><p>
                        <code class="code">run()</code> is no longer defined as final, but is
                        also no longer used by the front controller; it's sole
                        purpose is for using the class as a page controller. It
                        now takes two optional arguments, a
                        <code class="code">Zend_Controller_Request_Abstract $request</code>
                        and a <code class="code">Zend_Controller_Response_Abstract $response</code>.
                    </p></li>
<li><p>
                        <code class="code">indexAction()</code> no longer needs to be
                        defined, but is encouraged as the default action. This
                        allows using the RewriteRouter and action controllers to
                        specify different default action methods.
                    </p></li>
<li><p>
                        <code class="code">__call()</code> should be overridden to handle any
                        undefined actions automatically.
                    </p></li>
<li><p>
                        <code class="code">_redirect()</code> now takes an optional second
                        argument, the HTTP code to return with the redirect, and
                        an optional third argument, <code class="code">$prependBase</code>,
                        that can indicate that the base URL registered with the
                        request object should be prepended to the url specified.
                    </p></li>
<li>
<p>
                            The <code class="code">_action</code> property is no longer set.
                            This property was a <code class="code">Zend_Controller_Dispatcher_Token</code>,
                            which no longer exists in the current incarnation.
                            The sole purpose of the token was to provide
                            information about the requested controller, action,
                            and URL parameters. This information is now
                            available in the request object, and can be accessed
                            as follows:
                        </p>
<pre class="programlisting">
// Retrieve the requested controller name
// Access used to be via: $this-&gt;_action-&gt;getControllerName().
// The example below uses getRequest(), though you may also directly access the
// $_request property; using getRequest() is recommended as a parent class may
// override access to the request object.
$controller = $this-&gt;getRequest()-&gt;getControllerName();

// Retrieve the requested action name
// Access used to be via: $this-&gt;_action-&gt;getActionName().
$action = $this-&gt;getRequest()-&gt;getActionName();

// Retrieve the request parameters
// This hasn't changed; the _getParams() and _getParam() methods simply proxy to
// the request object now.
$params = $this-&gt;_getParams();
$foo = $this-&gt;_getParam('foo', 'default'); // request 'foo' parameter, using
                                           // 'default' as default value if not found
                        </pre>
</li>
<li>
<p>
                            <code class="code">noRouteAction()</code> has been removed. The
                            appropriate way to handle non-existent action
                            methods should you wish to route them to a default
                            action is using <code class="code">__call()</code>:
                        </p>
<pre class="programlisting">
public function __call($method, $args)
{
    // If an unmatched 'Action' method was requested, pass on to the default
    // action method:
    if ('Action' == substr($method, -6)) {
        return $this-&gt;defaultAction();
    }

    throw new Zend_Controller_Exception('Invalid method called');
}
                        </pre>
</li>
</ul></div>
</li>
<li><p>
                <code class="code">Zend_Controller_RewriteRouter::setRewriteBase()</code> has
                been removed. Use <code class="code">Zend_Controller_Front::setBaseUrl()</code>
                instead (or Zend_Controller_Request_Http::setBaseUrl(), if using
                that request class).
            </p></li>
<li><p>
                <code class="code">Zend_Controller_Plugin_Interface</code> was replaced
                by <code class="code">Zend_Controller_Plugin_Abstract</code>. All methods now
                accept and return a <a href="zend.controller.request.html" title="7.4. The Request Object">Section 7.4, “The Request Object”</a>
                object instead of a dispatcher token.
            </p></li>
</ul></div>
</div>
</div>
<div class="navfooter"><table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="zend.controller.exceptions.html">Prev</a> </td>
<td width="20%" align="center"><a accesskey="u" href="zend.controller.html">Up</a></td>
<td width="40%" align="right"> <a accesskey="n" href="zend.currency.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">7.12. MVC Exceptions </td>
<td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td>
<td width="40%" align="right" valign="top"> Chapter 8. Zend_Currency</td>
</tr>
</table></div>
<div class="revinfo"></div>
</body>
</html>
